As the popularity of playing multimedia content over the Web has increased the methods for accessing such multimedia content have continually improved. Initially, playing multimedia content (e.g., audio and video) was primarily a download-and-play technology. This method requires that an entire media file be downloaded from a Web server before it can be played. Thus, a media file becomes a local file on a client computer prior to being played back on the client Because media files are typically quite large, however, the download-and-play method can require a significant amount of time to download a media file before the file can be played back.
Another method for accessing multimedia content, called a progressive download, also uses a standard Web server to supply data (e.g., a compressed media file) to a client. In this method, however, the client begins playing back the media file before the entire file is fully downloaded from the server. Thus, the time between a media selection and the beginning of playback is typically much shorter with this method than with the download-and-play method previously discussed. Playback of the media file begins during the streaming of the file, once the client has buffered a few seconds of content. The buffering provides a small backlog of information so the media can continue to play uninterrupted, even during periods of high network congestion. With the progressive download delivery method, the client retrieves data as fast as the Web server, the network and the client will allow, without regard to the bit-rate parameter of the compressed media stream.
Streaming media servers provide still another method for accessing multimedia content. In the streaming media server method, a compressed media file is stored on a specialized streaming media server instead of a Web server. Unlike a Web server, which simply delivers data as fast as it can, a streaming media server can actively and intelligently send data to a client. The data is delivered at the data rate associated with the compressed media streams (e.g., audio and video streams), which is the exact real-time rate at which the data will be played back. The server and client communicate during the delivery process and the server can respond to feedback from the client. Among other benefits, the streaming media server's “just-in-time” manner of delivering data preserves network bandwidth that can be used to service more clients.
One important aspect of accessing media content, regardless of the method of delivery, is the ability to navigate the content and/or find specific locations within the content. However, the current methods discussed above for accessing/delivering multimedia content have significant disadvantages in this regard. For example, although some media players provide navigation functions such as fast forward and rewind, content delivery systems (e.g., Web servers, streaming media servers) may not support such accelerated or decelerated playback. Web servers, for example, are not configured to comprehend a client request for accelerated playback. In addition, even when streaming media servers support accelerated playback (or decelerated playback), the ability of a user to comprehend the content at the accelerated rate is greatly diminished because traditional streaming media servers simply drop data from media streams and only send “key frames” of video to achieve the accelerated rate. Thus, there is no true acceleration of the content. Rather, there is a “skipping” through the content. For example, a fast forward request (e.g., a request for 5 times the normal/real-time delivery/playback rate) from a client might result in the streaming media server sending only 1 video frame for every 8 seconds worth of content. This is approximately equivalent to dropping 239 out of every 240 video frames from a video stream. Thus, fast forwarding results in a jerky effect, as if a sequence of still images is being delivered. In addition, traditional streaming media servers typically drop the entire audio stream from the media content if asked to accelerate content delivery, because the servers assume there is not enough bandwidth to send the entire stream over the network at 5 times the real-time playback rate. Also, client based media players typically drop the audio stream when fast forwarding, even when playing a local file, because they assume that the fast forwarded audio playback produces high-pitched, “chipmunk” sounding audio that is mostly incomprehensible. Furthermore, any non-continuous, non-video/audio data stream (e.g., script commands for triggering events, captions, metadata) included within the media content, and synchronized to play at particular times during video playback, is typically lost due to the “skipping” through the video content.
One attempt to address the problems with navigating media content has been the development of “add-ons” for client media players. Add-ons are software additions that can be added onto an existing media player to provide an improved media content navigation experience. Although such add-ons may provide some benefits under certain circumstances, they have significant disadvantages. For example, such add-ons can provide an accelerated playback only when the media content is present in a local media file residing on the client computer. Thus, the drawbacks of the download-and-play method discussed above apply. Add-ons generally operate by tricking the underlying media player engine into consuming data at a faster rate while providing no mechanism for requesting accelerated delivery from a content delivery system (e.g., a streaming media server, a Web server). Thus, if the media content is not already presently available at the client in a local file, playback can only occur as fast as data arrives from a streaming media server or Web server. Therefore, use of add-ons when the media source is a streaming media server results in playback at the data rate associated with the compressed media stream being delivered to the client computer. When a standard Web server is the media source, use of an add-on can result in playback at rates that are various and unknown because the data delivery rate from the Web server depends on momentary network bandwidth availability and other varying factors. This can make it difficult or impossible to comprehend the media content. In addition, such add-ons provide no control over other functions of a media player because they are not an integral part of the player. Thus, use of an add-on can result in a loss of other basic controls on a media player such as “play”, “stop” and “pause”.
Accordingly, a need exists for an integrated and comprehensive solution capable of supporting variable play speed control for media streams.